Open Science Drone Toolkit: Open source hardware and software for aerial data capture

Despite the increased access to scientific publications and data as a result of open science initiatives, access to scientific tools remains limited. Uncrewed aerial vehicles (UAVs, or drones) can be a powerful tool for research in disciplines such as agriculture and environmental sciences, but their use in research is currently dominated by proprietary, closed source tools. The objective of this work was to collect, curate, organize and test a set of open source tools for aerial data capture for research purposes. The Open Science Drone Toolkit was built through a collaborative and iterative process by more than 100 people in five countries, and comprises an open-hardware autonomous drone and off-the-shelf hardware, open-source software, and guides and protocols that enable the user to perform all the necessary tasks to obtain aerial data. Data obtained with this toolkit over a wheat field was compared to data from satellite imagery and a commercial hand-held sensor, finding a high correlation for both instruments. Our results demonstrate the possibility of capturing research-grade aerial data using affordable, accessible, and customizable open source software and hardware, and using open workflows.

Both satellite imagery and hand-held sensors (such as the one used in our study) are among the tools most frequently used by farmers to monitor their crops, have been in use for around 20 years, and therefore can safely be considered as well-established, trusted, reference sensors (we included a comment and reference in the Discussion section to clarify this, lines 250-252) 1 . An "obvious" choice could have been another UAV, but none was available to us at the moment, and also the myriad of currently available platforms and sensors would have made it di cult to select one of them as reference (the citations added in line 255 [52][53][54][55] include many of those sensors, detailed in our response to Comment #10).

Abstract; reproducibility is mentioned as a benefit of the Open Science Drone Toolkit, though this is presented as a conclusion rather than an area of inquiry; how does one ascertain reproducibility and what about replicability and other stakeholder interests?
As indicated previously, R&R terminology has been clarified, and therefore the reference to reproducibility in its generic sense was removed from the Abstract and the Conclusions. Our work does not attempt to evaluate the reproducibility of our computational methods nor the replicability of the results obtained with the OSDT, as it would be out of the scope of the paper. We have therefore revised the text and removed any references to the reproducibility or replicability of the methods and results of our paper. In the Introduction section, however, several references are cited which argue that open source hardware and software can be beneficial for R&R. These references were kept, but we clarified the terminology as per the NASEM (2019) report (details in the response to the following comment). The use of R&R terminology was revised throughout the manuscript, following the NASEM (2019) report, as detailed here:

Line
Lines 31-32: "reproducible" was removed (open source software and open data provide increased transparency which could arguably contribute to reproducibility, but the reproducibility of our computational workflows was not assessed) Line 36: "reproduction" was replaced by "replication" (we meant reproduction in the generic sense, but this idea is more clearly conveyed by the term replication as defined in the NASEM report) Line 42: "reproduction" was replaced by "replication or reproduction" (access to scientific instruments, materials and software is necessary both for computational reproducibility or for attempting a complete replication of a previous study) Line 50: "reproducibility of published results" was replaced by "reproducibility of published results or replication attempts" (both computational reproducibility using the same tools and data, and independent replication attempts can benefit from having access to the same tools used in the original studies) Line 253: "reproducible and repeatable measurements" was replaced by "robust measurements" (the terms used in the paper cited to assess the quality of the measurements were not in line with the NASEM terminology, so they were replaced with a more general term) Line 271: "reproducibility" was left unchanged (it refers to computational reproducibility being hindered by lack of data sharing standards) Line 292: "reproducible" was removed (same reason as in the Abstract)

Line 44; if the user makes improvements to open source software, as described here, does that contribute to (or detract from) its benefits for others?
This sentence refers only to the freedoms conferred to the user when software is openly licensed. Any changes to a software can only impact other users as long as the modified version is further distributed. This is the same for proprietary or closed-source software, the di erence being that in this case only the original developer can (legally) make those changes. In recent years, with the advent of subscription cloud platforms and software-as-a-service, the final user is usually not aware of software changes or updates, since they function as a "black box". In the case of open-source software, the "risk" of many people being able to make changes is accompanied by the possibility of inspecting the code and e ectively checking those changes against previous versions. We have not included any additional comments in the manuscript text, since these concepts apply to all openly licensed works and we therefore believe it is out of the scope of our paper to discuss it more deeply. The reader can refer to the literature already cited [10][11][12][13][14][15][16] for further details on this topic.

6.
Lines 100-102; the statement that the hardware which is not open-hardware can be "readily replaced" doesn't make sense in the context of the study; if the various commercial components such as Windows computers are convenient, why not commercial drones?
In contrast with open source software, open source hardware is virtually impossible to be 100% open source, and therefore uses the concept of "available components" (https://ohwr.org/project/cernohl/wikis/faq#q-what-are-available-component )s or "readily-available components and materials" (https://www.oshwa.org/definition/). The OSDT components that are referred to in lines 102-103 are those that can e ectively be replaced without significantly altering the technical specifications of the system. It is not expected that the capabilities of the system will be significantly altered by using a di erent computer, smartphone or radio transmitter (since the drone flies autonomously), as long as they are compatible. This might not be the case for the camera, for which di erent brands or models could have widely varied capabilities, and therefore we suggest the use of a specific brand.
A commercial drone could indeed be used as a complete replacement, but this generally also requires the use of a dedicated closed-source software, has limited customization options, etc. The aim of our work was to reduce the use of proprietary technologies as much as possible, therefore maximizing the user freedoms and the advantages of open tools. 7. P. 6; when referencing "GPS", this would typically refer to Global Positioning System which is a United States platform; wouldn't this benefit from a more generic reference, given international scope?
This was corrected as suggested: Table 1: "GPS-guided flight" was replaced by "satellite-guided flight" Table 1: "GPS coordinates" was replaced by "coordinates" Line 94: "GPS capability" was replaced by "satellite navigation capability" Table 2: "GPS recorder" was replaced by "Location recorder app" Line 111: "GPS" was replaced by "GNSS (Global Navigation Satellite System)" Line 142: "GPS location data" was replaced by "location data" Line 193: "GPS logging app" was replaced by "location recorder app"

Line 185; I doubt Sentinel 2 imagery can be used to "validate" drone imagery that has a spatial resolution of 2 x 2 cm; these are very di erent sources and it is not clear what is meant by "validate"; I would strongly suggest including these e orts as a comparison but not as a validation 9. The use of the handheld sensor is helpful, though still a comparison rather than a validation; I believe the latter would require a far more sophisticated process which draws deeply upon literature regarding error expression and propagation as well as uncertainty
The objective in both cases was indeed to provide a comparison and not a validation, and it is referred to as such many times throughout the manuscript (lines 28, 203, 215, 223, 227, 248, 289). The term validation was wrongly included in this sentence, and has been corrected (line 188).

You can reference literature that has already done extensive work on low altitude drone imaging using commercial sensors, and its comparisons with reference data; the fact that you are using an open hardware drone should not change the fundamental process of low altitude aerial image streams
In the paragraph in lines 247-258, our results are discussed in relation to some of the (indeed extensive) literature on UAV aerial imaging, and particularly the comparison of similar sensors (RGB cameras) to other sensors (multispectral cameras and LiDAR systems  [52]. As pointed out by the Reviewer, our work should only aspire to provide a comparison to reference instruments, since a true validation would indeed require a sophisticated procedure which is beyond the scope of our paper.

Review Comments to the Author -Reviewer #2
Thanks for the opportunity to review this paper, I really enjoyed reading it an learning about your work! The paper is well written and provides documentation of interesting science that is well aligned with my area of interest. I have attached my comments in the document and hopefully they prove useful for you in a minor revision.
We appreciate the reviewer's comments and valuable suggestions. All the in-line comments in the manuscript have been addressed, as detailed below.
I also suggest that the figure quality needs to be increased -they are quite blurry on my screen.
The figures are shown in low resolution in the PDF, but are uploaded in the required resolution in the editorial platform.

Comments in the document:
Line 48: Comment: Might be worth noting that sometimes a disadvantage is that often open hardware and software is developed through a grant or similar and has no business model to maintain, sustain, or further develop [...] We agree with the concerns about the sustainability of open source projects. We have added a paragraph on this issue in the Discussion section (lines 259-267).
Line 69: "The objective of this work was to address this question by collecting, curating, organizing and testing…" -Comment: processing? analysing?
We kept this phrase unchanged, since we consider that the processing and analysis of the data is included in the "testing" step Line 108: Comment: I like the name Thanks! Line 122: "...with approximately 30% of battery capacity remaining to return to the launch site and land safely." -Comment: Caveat that this is based on how far away (horizontally and vertically) the drone is from the home point, noting that there should be 20% battery remaining on landing We agree that the time necessary to return to the launch site and land should be considered in the total flight time, and that there should be at least 20% battery remaining after that. We tried to make a conservative estimate considering 30% battery remaining, but it is true that our phrasing implied that that "extra" 10% would be su cient for returning to the home point and landing in all cases, which is not correct. We therefore modified the sentence so as to avoid this (line 124).
Line 144: "This process is called geotagging … and can be performed using the Mission Planner ground station software." -Comment: as long as you remember to set the time properly on the camera This is indeed an important thing to consider, and as such it is included in the "usage guide" of the OSDT. Also, since it is something that is easy to forget, an alternative is to measure the time o set afterwards, and use that o set in the geotagging tool.
Line 202: Comment: I'm missing in this paragraph the height of the sensor from the feature, it's FOV, and therefore the 'footprint' of the measurement. Also maybe something about how the measurements were geo-located?
The missing information was included (lines 211-214)

Lines 202-208: [various corrections]
The text was corrected as suggested Line 214: Comment: Would be good to note the spatial accuracy of the GPS and how you are e ectively tying 2cm (GSD from drone image) to a satellite image and field data measurements when presumably there could be meters discrepancy? I understand that you can't resolve for this within the scope of the study, but would like to see recognition of this issue We included a sentence which warns about this possible discrepancy in the case of the drone-satellite comparison (lines 205-208). In the case of the handheld sensor-drone comparison, a visible physical mark combined with ground measurements and the aid of the crop rows was used to aid in the correspondence (lines 211-213). We agree about the possibility of commercial applications, but the scope of our work and the toolkit is scientific applications. We did not imply either lower or higher level, but requirements that are specific to scientific work (e.g., not only being able to provide a valid measurement but also being transparent about the algorithms that lead to that result). We nevertheless included a small comment to suggest the possibility of commercial applications (line 237).
Line 234: I think that it's often the commercial sector that perhaps hints at the 'quality' or lack thereof of open source (perhaps a reasonable tactic to keep themselves in business, which of course is necessary for them too), but the reliability side of things can be a real issue (see my point in the intro. As indicated in the response to the first comment, a paragraph on this topic was added to the Discussion section (lines 259-267).
Line 239: Comment: I would also argue that in many cases, the high spatial resolution is just as, if not more important the gaining an extra couple of bands. Multispec cameras are notoriously low in spatial resolution, and people who don't understand this trade o relationship are often left disappointed with their purchases. The Phantom multispec for example is 2MP vs 20MP for their standard RGB (I know you are going with open source, but just for comparison here). Another thought actually could be to hack a canon or similar to remove the NIR filter and then put filters back on in the wavelengths of interest -that would be more in your flavour and keep the spatial resolution of the sensor.